This doesn't work as vectors that are 4 wide are restricted behind a FFlag because they increase the size of a TValue so they can fully fit on the stack.

Although I do think there is value in making vectors more generalized, as I've commonly ran into situations where I'm using vectors that don't necessarily have an x or y. Like for instance an RGB color represented as a vector; it'd be nice to be able to create a vector alias that allows for accessing the components using r,g, and b.
But that's a ways away, as currently the compiler doesn't actually use the type solver. Plus the solver isn't stable enough to where that could be a possibility, although it is close currently.

This doesn't work as vectors that are 4 wide are restricted behind a FFlag because they increase the size of a TValue so they can fully fit on the stack.

Potentially for larger vectors a reference/pointer could be used similarly to how buffers are.
This would add overhead but should still be much faster than other solutions.

One concern I can think of with the "auto-switch between 3/4 size and 'large' size" approach is how it would interact with NCG. vector operations are able to make use of SIMD, but if the size of a vector can no longer be statically determined those optimisations are going to struggle. I could see the possibility for foo (a: vec, b: vec) if (a.dim == 4 and b.dim == 4) { SIMD path } else { slow path } but that's not especially ideal or pretty. Someone who's more familiar with the precise inner-workings of NCG might be able to provide a solution to that problem though.